home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Internet
/
Collection of Internet.iso
/
faq
/
comp
/
oberon_f
/
language
< prev
next >
Wrap
Text File
|
1994-04-08
|
11KB
|
285 lines
Newsgroups: comp.lang.oberon,comp.answers,news.answers
Path: bloom-beacon.mit.edu!hookup!news.kei.com!eff!usenet.ins.cwru.edu!agate!library.ucla.edu!psgrain!m2xenix!mikeg
From: mikeg@psg.com (Mike Gallo)
Subject: Comp.lang.oberon FAQ (monthly)
Expires: Sun, 1 May 1994 07:00:00 GMT
Reply-To: mikeg@psg.com
Organization: PSGnet, Portland Oregon US
Date: Fri, 8 Apr 1994 12:05:45 GMT
Approved: news-answers-request@MIT.Edu
Message-ID: <1994Apr8.120545.15151@psg.com>
Followup-To: comp.lang.oberon
Summary: This posting contains a list of Frequently Asked Questions
(and their answers) about Oberon. It should be read by anyone
who wishes to post to the Comp.lang.oberon newsgroup.
Lines: 267
Xref: bloom-beacon.mit.edu comp.lang.oberon:1740 comp.answers:4821 news.answers:17827
Archive-name: Oberon-FAQ/language
(* * * * * * * * * * * * * * * * * * * * * *)
Many FAQ lists, including this one, are available by anonymous
ftp from rtfm.mit.edu in the /pub/usenet/news-answers directory.
Thanks to all who have contributed! Further additions,
corrections, and suggestions are welcome.
mikeg@psg.com
(* * * * * * * * * * * * * * * * * * * * * *)
Comp.lang.oberon Frequently Asked Questions
The Programming Language
Copyright 1994 Michael Gallo
(c) 1994 Michael Gallo
THE PROGRAMMING LANGUAGE OBERON
From "From Modula to Oberon"
The programming language Oberon is the result of a
concentrated effort to increase the power of Modula-2 and
simultaneously to reduce its complexity. Several features were
eliminated, and a few were added in order to increase the
expressive power and flexibility of the language. This paper
describes and motivates the changes. The language is defined
in a concise report.
Whereas modern languages, such as Modula, support the
notion of extensibility in the procedural realm, the notion is
less well established in the domain of data types. In
particular, Modula does not allow the definition of new data
types as extensions of other, programmer-defined types in an
adequate manner. An additional feature was called for, thereby
giving rise to an extension of Modula.
. . . .
The evolution of a new language that is smaller, yet more
powerful than its ancestor is contrary to common practices and
trends, but has inestimable advantages. Apart from simpler
compilers, it results in a concise defining document, an
indispensable prerequisite for any tool that must serve in the
construction of sophisticated and reliable systems.
Among the eliminations in the move from Modula-2 to Oberon are
variant records, opaque types, enumeration types, subrange types,
the basic type CARDINAL, local modules, and Modula's WITH
statement. The major addition to Oberon is the concept of type
extension (i.e., single inheritance) for records.
OBJECT ORIENTED PROGRAMMING IN OBERON
Oberon does not offer multiple inheritance. However, it has
been shown that multiple inheritance can be efficiently implemented
in terms of single inheritance and been argued that MI is therefore
syntactic sugar that is rarely used in practice. For details, see
Templ (1993) and Mssenbck (1993).
Oberon does not offer built in "methods" as do many other
languages supporting OOP. Instead, conventional virtual methods
can easily be implemented by a pointer to a procedure table, or
"messages" can be sent to procedures as extensible records.
While some people complain about Oberon's minimalistic support
of object oriented programming, others feel that this is one of
Oberon's strengths, that the language does not institutionalize a
particular approach to OOP (see the Comp.object FAQ list for an
examination of several variations on the object oriented paradigm).
For another discussion, see Oberon2.OOP by H. Mssenbck.
THE PROGRAMMING LANGUAGE OBERON-2
From "Differences between Oberon and Oberon-2"
Oberon-2 is a true extension of Oberon. . . .
One important goal for Oberon-2 was to make object-
oriented programming easier without sacrificing the conceptual
simplicity of Oberon. After three years of using Oberon and
its experimental offspring Object Oberon we merged our
experiences into a single refined version of Oberon.
The new features of Oberon-2 are type-bound procedures
[i.e., virtual methods], read-only export of variables and
record fields, open arrays as pointer base types, and a with
statement with variants. The for statement is reintroduced
after having been eliminated in the step from Modula-2 to
Oberon.
THE "OBERON FAMILY" OF LANGUAGES
Object Oberon is a now defunct, experimental extension of
Oberon featuring "classes", structures somewhere between modules
and records. It evolved into Oberon-2.
Seneca was also an experimental extension of Oberon. It
focused on numerical programming on vector computer architectures.
It evolved into Oberon-V.
Oberon-V is an experimental dialect (but not a superset) of
Oberon. It is concerned with issues of numerical computing, array
processing, and code verification. It's primary new features are
the ALL statement (a parallel version of the FOR loop) and array
constructors for actual open array parameters. Since it was
originally aimed at vector architectures in general and the Cray Y-
MP in particular, no Oberon-V compiler has yet been implemented for
the Oberon System. For details, see Griesemer (1993).
COMMON PROBLEMS PROGRAMMING IN OBERON
The WITH statement
"This [compiler error] has to be a bug, correct me if I'm wrong!
(I'm going nuts over this)"
TYPE
Obj* = POINTER TO Empty;
Empty = RECORD (*nothing*) END;
OpObj = POINTER TO OpNode;
OpNode = RECORD (Empty)
name : CHAR;
left, right : Obj;
END;
PROCEDURE doeval(ex: Obj): REAL;
BEGIN
WITH ex : OpObj DO
CASE ex.name OF
"+" : RETURN doeval(ex.left) + doeval(ex.right);
(* clever code here *)
END;
(* more clever code here *)
END;
END doeval;
As thutt@clark.net (Taylor Hutt) points out,
. . . this is not a bug. The WITH statement actually changes
the static type of the WITHed variable for the entire duration
of the WITH statement.
A workaround to this problem is to assign the parameter
to a temporary variable and to use the WITH on the temp. A
type guard will not work properly in this case, do not attempt
to use it.
Some people on Comp.lang.oberon think that because of its non-
local effects, the WITH statement should be avoided entirely. They
point out that a programmer can use individual type guards or, if
a guarded variable is used very many times, pass the variable to a
procedure.
BIBLIOGRAPHY
Sources cited in the FAQ list that are not listed in the
bibliography are electronically available in PostScript and/or
Oberon text formats from ETH Zrich. They can be acquired by
anonymous ftp from:
ftp.inf.ethz.ch:/Oberon,
wuarchive.wustl.edu:/languages/Oberon, and
gatekeeper@dec.com:/pub/plan/Oberon
"Type Extensions" by N. Wirth; ACM Transactions on Programming
Languages and Systems; 10, 2 (April 1988) 204-214.
"From Modula to Oberon" by N. Wirth; Software: Practice and
Experience; 18,7 (July 1988) 661-670.
"The Programming Language Oberon" by N. Wirth; Software: Practice
and Experience; 18,7 (July 1988) 671-690.
"Variations on the Role of Module Interfaces" by J. Gutknecht;
Structured Programming; 10,1 (January 1989) 40-46.
"Object Oberon -- A Modest Object-Oriented Language" by H.
Mssenbck and J. Templ; Structured Programming; 10,4 (April 1989)
199-207.
A New Approach to Formal Language Definition and Its Application to
Oberon by M. Odersky; Verlag der Fachvereine Zrich; 1989.
"The Programming Language Oberon-2" by H. Mssenbck and N. Wirth;
Structured Programming; 12,4 (April 1991).
Programming in Oberon: Steps Beyond Pascal and Modula-2 by M.
Reiser and N. Wirth; ACM Press; 1992.
"A Systematic Approach to Multiple Inheritance Implementation" by
J. Templ; ACM SIGPLAN Notices; Volume 28, Number 4 (April 1993).
Object Oriented Programming in Oberon-2 by H. Mssenbck; Springer-
Verlag; 1993.
A Programming Language for Vector Computers by R. Griesemer; Swiss
Federal Institute of Technology (ETH Zrich); Dissertation Number
10277, 1993.
OBERON COMPILERS
Please note that mention of a product or company does not
necessarily imply a recommendation. For Oberon compilers developed
outside ETH Zrich contact:
VAX/VMS:
ModulaWare GmbH, Wilhelmstr. 17A, D-91054 Erlangen/F.R.Germany
Modula-2 & Oberon-2 Compiler Manufactur
Tel. +49 (9131) 208395, Fax +49 (9131) 28205.
E-mail/Internet:
100023.2527@compuserve.com
g_dotzel@ame.nbg.sub.org
MS-DOS and Windows:
ModulaWare GmbH, Wilhelmstr. 17A, D-91054 Erlangen/F.R.Germany
OM2 32 Bit Oberon-2 and Modula-2 Compiler for PC/DOS
'386/'486 native code for DOS with DPMI Driver/Host and
for DOS sessions under Windows 3.1 and OS/2 2.1
COP2 (partial Oberon to C translator)
contact Taylor Hutt, e-mail: thutt@clark.net
Oberon-M
contact E. Videki, e-mail: erv@k2.everest.tandem.com
Extacy
Real Time Associates Ltd.
Canning House, 59 Canning Road
Croydon, Surrey, CRO 6QF
England
Tel.: 0044-81-656 7333
Fax: 0044-81-655 0401
E-mail: 71333.2346@compuserve.com
rta@rtal.demon.co.uk
Pow! (Programmers Oberon Workbench)
It works with Microsoft Windows and can be used to create
native Windows applications (EXE's and DLL's).
Ftp: ftp.fim.uni-linz.ac.at:/pub/soft/pow-oberon2, or
galileo.meakins.mcgill.ca:/Oberon/CommercialDemos/POW
E-mail: pow@fim.uni-linz.ac.at
Mailing list: majordomo@fim.uni-linz.ac.at "subscribe
pow-list"
Amiga:
A+L AG
Daederiz 61
CH-2540 Grenchen
Tel.: +41 (65) 52 03 11
DECstation (Ultrix, OSF/1), Intel386 (SVR4, OS2, Solaris), Sparc
(Solaris):
Office of Commercial Services
Queensland University of Technology
GPO box 2434, Brisbane Q4001
Australia
Atari:
Martin Momberg
Hahlgartenstr. 13a
D-64331 Weiterstadt
Germany
E-Mail: Inet:momberg@dik.maschinenbau.th-darmstadt.de
Ftp: ftp.th-darmstadt.de:
/pub/machines/atari/programming/stoberon
--
A designer knows he has arrived at perfection not when there
is no longer anything to add, but when there is no longer
anything to take away.
-- Antoine de Saint-Exupery